I. Field of the Invention
This invention relates to transmitting data, including1 multiple channels of data, via a computer network from a point or points of origin to a plurality of end-users. It has numerous exemplary2 embodiments, including real-time transmission of data pertaining to live events (such as performances, exhibitions, competitions, presentations, or tours), displays of audiovisual recordings (such as movies or television), advertising, coordinating group activities, or assisting the hearing or visually impaired. It makes use of computer networking technologies associated with the Internet and World Wide Web (the “iWeb”). 1 As used herein, the term “include,” in all its conjugations and forms, means “include without limitation.”2 Any thing or group of things referred to herein as “exemplary,” an “example,” “for example,” or illustrative, or introduced by the term “such as,” is included for purposes of illustration, and not to indicate that other, equally illustrative things, do not exist.
II. Background on Browsers, Structured Documents, and Client/Server Scripting
A “browser” is a software application that enables its user, among other things, to locate, display, and interact with text, sound, and static and moving image files.3 A browser can “download” (i.e., access) such files whether they are stored locally (on the same computer4 as the browser) or remotely (on a separate computer). Such files may be stored at a remote Web site accessed via the Internet, on a remote computer within a local area network (a “LAN”), or in a file system stored locally on the same computer as the browser. A browser may locate and request to download a file by reference to the file's Uniform Resource Identifier (“URI”).5 3 As used herein, the term “file” refers to stored data. This is for ease of reference only, and in and of itself does not imply any specific type of data or structure for storing the data.4 As used herein, the term “computer” refers to an apparatus that includes the components of a central processing unit microprocessor (CPU), read only memory (ROM), random access memory (RAM), a basic input/output system software application (BIOS), an operating system software application (OS), data storage capacity, and some combination of input/output (I/O) devices (such as a screen (including a touchscreen) or other display medium, keyboard, mouse, trackpad, trackball, microphone, or audio speaker).5 See, e.g., T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifier (URI): Generic Syntax, Request For Comments 3986, The Internet Society (2005), available at ietf.org/rtfe/rfc3986.txt (last accessed Jul. 15, 2009).
If a file is stored remotely, the browser requests and downloads it via a network connection with the computer on which the file is stored, using a network communication protocol such as the HyperText Transfer Protocol (“HTTP”). Network communication protocols provide a means for computers to communicate across networks. They set rules for how computers should identify and connect with each other, and how they should format data for transmission and receipt. Broad adoption of standardized protocols enables numerous heterogeneous computer systems to communicate seamlessly over a network. HTTP, for example, is a broadly adopted standard that is one of the primary protocols upon which the Web is based.6 6 See, e.g., R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter. P. Leach, T. Berners-Lee, Hypertext Transfer Protocol—HTTP/1.1. Request For Comments 2616, The Internet Society (1999), available at w3.org/Protocols/rfc2616/rfc2616.txt (last accessed Jul. 15, 2009).
Browsers also “render” structured document files. A structured document file is a text file that, among other things, has been coded or annotated with a markup language. A markup language provides instructions for how text should be structured or formatted upon display.7 A browser renders a structured document file by displaying it in accordance with the browser's interpretation of such instructions. One example of a markup language is the HyperText Markup Language (“HTML”). The majority of the content available on the Web has been coded in HTML or the related Extensible HyperText Markup Language (“XHTML”). XHTML is a reformulation of HTML in accordance with the Extensible Markup Language (“XML”), which is a specification for creating custom markup languages.8 The term “markup language,” as used herein, refers to HTML, XHTML, another XML-conforming markup language, or any markup language performing functions equivalent to those ascribed to markup languages herein. 7 See, e.g. James H. Coombs et al. Markup Systems and the Future of Scholarly Text Processing, Communications of the ACM 30, at 933-47 (November 1987), available at xml.coverpages.org/coombs.html (last accessed Jul. 15, 2009).8 See, e.g., World Wide Web Consortium (“W3C”), HTML 4.01 Specification, Dec. 24, 1999, available at w3.org/TR/html401/(last accessed Jul. 15, 2009); W3C, XHTML™ 1.0 The Extensible HyperText Markup Language, Jan. 26, 2000 recommendation revised Aug. 1, 2002, available at w3.org/TR/xhtml1/ (last accessed Jul. 15, 2009). XML has been gaining popularity on the Web as well, and is itself a subset of the Standard Generalized Markup Language (“SGML”) of the International Organization for Standardization (ISO 8879:1986 SGML). See, e.g., W3C, Extersible Markup Language (XML) 1.1, Aug. 16, 2006, available at w3.org/TR/xml11/(last accessed Jul. 15, 2009).
A structured document file also may contain one or more hyperlinks. A hyperlink may designate, among other things, the URI of another structured document file.9 When activated by a browser's user, such a hyperlink induces the browser to download and render the designated file in place of, or in addition to, the initial file that contains the hyperlink. A browser thereby enables its user to traverse a plurality of hyperlinks, and thereby “browse” or “surf” a collection of interlinked structured document files. 9 See, e.g., HTML 4.01 Specification, supra note 8, §12 (Links), available at w3.org/TR/html401/struct/links.html.
A structured document file also may contain or be accompanied by a client-side script. A client-side script is a program or set of instructions that the browser and the computer it resides on (jointly and individually referred to as a “client”) execute upon downloading the associated structured document file, or upon a later triggering event, such as the user's activation of a hyperlink designating the client-side script.10 10 See, e.g., HTML 4.01 Specification, supra note 8. §18 (Scripts), available at w3.org/TR/html401/interact/scripts.html.
A structured document file also may contain a server-side script. A server-side script is a program that is executed by the computer or software application that is “serving” (i.e., transmitting) the structured document file to the browser. Execution of the server-side script is prompted by the browser's request to download the structured document file.11 11 See, e.g. Robert E. Irie, Web Site Design, The Internet Encyclopedia, vol. 3, 768, 770-71 (Hossein Bidgoli ed., 2004).
Browsers widely available today include, for example, Internet Explorer, Firefox, Safari, Chrome, and Opera. It will be appreciated by one skilled in the art, however, that the invention may be practiced with other software applications. The term “browser,” as used herein, refers to any software application capable of performing functions equivalent to the functions ascribed to browsers above, whether or not they are its primary functions.
It will be appreciated by one skilled in the art that the invention may be practiced also by means of a “push” design not typically associated with standard browser implementations. A push design differs from its opposite, a pull design, in that the client passively listens for initiation of a file transfer from a remote server, instead of actively requesting it. Examples of broadly adopted communication protocols with push designs include the Short Message Service (“SMS”) on the GSM wireless phone network, and SMTP-based Internet email (“Simple Mail Transler Protocol”). The “Server-Sent Events” and “Web Sockets” protocols, which are still in development, are examples of draft specifications of push standards intended for adoption by mass-distribution Web browsers. 12 12 See, e.g. W3C, Server-Sent Events. W3C. W3C Working Draft, Apr. 23, 2009, available at w3.org/TR/2009/WD-eventsource-20090423 (last accessed Jul. 12, 2010): The Web Sockets API, W3C Working Draft, Apr. 23, 2009, available at w3.org/TR/2009/WD-websockets-20090423 (last accessed Jul. 12, 2010); Ian Hickson, The Web Socket Protocol, draft-hixie-thewebsocketprotocol-22 (Jul. 13, 2009), available at tools.ietf.org/html/draft-hixie-thewebsocketprotocol-22 (last accessed Jul. 12, 2010).
III. Prior Art
Various prior art has addressed or touched upon the transmission of successive data units via a computer network, including for supplementing live events or presentations of audiovisual recordings, for advertising, for coordinating group activities, or for assisting the hearing impaired.
U.S. Pat. No. 5,739,869 to Markle et al. (1995) describes a multichannel electronic libretto display apparatus and method that is “broadcast only” (Markle at col. 1, line 57)—i.e., its network communications travel in one direction, from the data source to the end-user recipients. The Markle patent relies on a specialized transmission protocol to send all data channels in a single data packet. The entire packet, with all channels, must then be loaded and stored by every end-user device in a memory butffer in advance of display. A second data packet containing a “display cue” must then be transmitted to all end-user devices, to trigger each end-user device to display the portion of the previously downloaded packet that corresponds to the channel the end-user has chosen to view.
A limitation of the Markle patent's system is that “[t]he number of channels available is dependent on the buffer size incorporated into the display unit.” (Markle at col. 5, line 25-26.) The system also is limited to transmitting a “preselected sequence of text.” (Id. at cols. 8-10.) In addition, all channels must proceed in a synchronized manner, with each display cue sent to every end-user device simultaneously. Nor is a means provided to integrate the preselected sequence of text with other content that end-users may browse in a self-directed fashion. The system also relies on custom communication protocols and end-user device configurations, increasing expense and limiting practicality of implementation.
U.S. Pat. No. 6,760,010 B1 to Webb et al. (2004) discloses a wireless electronic libretto display apparatus and method that, like the Markle patent, is limited to one-way communications. The Webb patent improves upon the Markle patent's transmission protocol by appending a cyclical redundancy checksum (“CRC”) to the data packets, as a means of avoiding data corruption in electromagnetic wireless transmissions. Upon receipt of a data packet, each end-user device recalculates the CRC itself, and if the recalculated CRC does not match the CRC received, the device discards the packet and waits for it to be retransmitted.
While introduction of the CRC process improves accuracy of data transmissions, the Webb patent otherwise describes a system that remains essentially the same as that of the Markle patent, and remains subject to equivalent limitations. The CRC also introduces new limitations insofar as data packets must be rebroadcast repeatedly by the main control unit and transmitter, and the network communication protocols and end-user device configuration must be more specialized. The Webb patent explains that it relies exclusively on one-way transmissions because “[t]wo-way communications are not practical” due to the “large bandwidth required, the complicated protocol and the cost of the implementation, particularly with large installations.” (Webb patent at col. 1, lines 39-43.) That statement no longer describes the state of the art accurately, thanks to rapid advancement of computer networking technologies, including the recent availability of inexpensive mass-market wireless networking systems and devices.
U.S. Pat. No. 6,785,539 B2 to Hale et al. (2004), the continuation U.S. Pat. No. 7,224,967 to Hale et al. (2007), and the related continuation application U.S. application Ser. No. 11/679,147 by Hale et al. (filed Feb. 26, 2007) (collectively, the “Hale Patents”) describe a system and method of wirelessly triggering portable devices to display data to end-users for various purposes, including to provide captioning for a performance or attraction. The Hale Patents' system relies upon “pre-loading” and “pre-programming” end-user devices with the content to be displayed. Thereafter, a series of specialized data packets are transmitted to the end-user devices, with each packet containing instructions to “trigger” the end-user-devices to display the appropriate portion of the content with which they already have been loaded. The need to pre-load the end-user devices in advance of display, and the reliance upon specialized communication protocols, are cumbersome and limiting. Data units cannot be created and transmitted in real time in response to occurrences during the course of a live event. In addition, the expense and difficulty of implementing the system described by the Hale Patents are increased.
U.S. Pat. No. 5,648,789 to Beadles et al. (1997) describes wireless transmission of captions for hearing-impaired attendees at theatrical and similar performances. Its teachings, however, are limited to a method whereby each end-user wears a specialized apparatus in the form of eyeglasses that superimposes the captions within the end-user's field of vision. The apparatus described has certain inherent limitations, including that it only can display from 60 to 90 alphanumeric characters at a time. (Beadles at col. 3, lines 37-38.) Nor does the Beadles patent's system provide for transmitting multiple channels, or integrating the captions with content that end-users may browse on a self-directed basis. In addition, the fact that the specialized eyeglasses apparatus is not yet widely used or available to consumers imposes cost and practicality limitations.
U.S. Pat. No. 6,396,500 to Qureshi et al. (2002) describes a method for converting the format of a series of slides that have been created with a slide presentation program, such as “Power Point,” into a series of corresponding HTML pages for successive display in a browser or equivalent viewing facility. By use of the well recognized HTML standard and widely available browser applications, the Qureshi patent overcomes some of the cost and practicality limitations associated with other prior art discussed above. However, it describes no means for real-time centralized control and coordination of the content displayed by multiple distributed end-user devices.
The Qureshi patent's method therefore is not useful for supplementing live events. It is ill-suited for this, as well, because it describes no means to transmit multiple channels in parallel. In addition, it transmits entire HTML pages in series, with each HTML page constituting a single slide. This transmits more data than necessary, causing suboptimal transmission times and network resource expenditures. Each successive HTML, page also must be reloaded by the browser, a process that is a further source of delay and tends to disturb or disrupt the browser's display medium. Delay is especially significant in the live event context, where supplemental data transmissions typically must keep close pace with numerous, short occurrences during the longer event.